나는 중학생 때 게임 제작 툴을 이용하며 자연스레 코딩을 접했다. 단순히 다른 사람들이 짜놓은 스크립트를 보며 그 형태를 이해하는 식으로 코딩을 했었기 때문에 프로그래밍을 제대로 했다고 할 순 없다. 하지만 그때의 경험이 큰 도움이 되었다고 느낀다.
고등학생 때 우연히 웹 프로그래밍 수업을 듣게 되었는데 뭔가 너무 익숙해서 의기양양했던 기억이 있다. 프로그래밍이 무엇인지 알게된 뒤 본격적으로 프로그래밍에 대해 배우고 싶어 연이어 컴퓨터 과학 수업을 수강했다.
대학 입시를 위해 여러 학교 사이트를 넘나들며 봤던 것 중 가장 흥미로웠던 것은 한 학교의 학부 연구생 프로그램 이었는데, 바로 귀가 들리지 않는 사람들도 음악을 즐길 수 있도록 시스템을 만드는 프로그램이었다. 그때부터 사람을 도울 수 있는 도구로써 컴퓨터를 달리 보게 되었다.
그때도 그렇고 지금도 그렇고 오로지 컴퓨터 그 자체만을 파고싶지는 않다. 그저 잘 배워두면 내가 원하는 방향으로 세상을 이롭게 할 수 있지 않을까. 물론 그전에 다른 덕목이 선행되어야 하겠지만...
프론트엔드 웹 개발은 진입장벽은 낮지만 러닝커브는 점점 가팔라진다 (하키 스틱). 웹을 이용해서 당장 눈에 보이는 뭔가를 대충 만드는 건 매우 쉽지만 프로덕션 상황에 이런 저런 요구사항이 하나 둘 붙기 시작하면 생각치도 못한 장애물이 많이 나타난다. 요즘은 웹으로 정말 많은 걸 할 수 있지만 그만큼 신경써줘야하는 코너 케이스도 많은 것 같다. 맞닥뜨리는 문제가 워낙 구체적인 경우도 많아서 나중에 별 도움이 안될지도 모르지만 일단 기록은 해둬야겠다.
어쩌다보니 회사를 다니며 [[웹 개발]]을 하게 됐다. 회사에서 처음 다수의 손길이 거쳐간 코드 베이스를 봤을 때 이해하는데 어려움이 있었다. 단순히 내가 처음이라 서툴러서 이해를 못하는 건가 싶었는데, 구조가 제대로 잡혀있지 않은 코드가 원인이었다. 난 정리되지 않은 코드를 보기 싫었기 때문에 코드 정리를 하기 시작했는데 그러다보니 어떨결에 주업무로 리팩토링을 하게 되었다. 그 뒤로 [[관리하기 쉬운 코드]], 클린코드가 무엇인지, 어떻게 하면 기능이 계속 추가되는 상황에서 관리가 가능한 코드베이스를 유지할 수 있을지에 대한 고민을 많이 하게 되었다. 그러던 중 [[기술 부채]]에 관한 블로그 글을 하나 발견했는데 공감되는 부분이 많았다. 그 어느 회사를 가도 레거시 코드는 있을 것이다. 이를 어떻게 해결할 지 빨리 결단을 내리는 것이 중요할 듯 싶다.
여러명이 같이 일해야하는 환경에서 단순히 코딩을 잘하는 것은 그리 큰 이점이 아닌 듯 하다. 게다가 사람마다 선호하는 코딩 방식의 차이가 있기 때문에 일정 수준 이상 객관적으로 판단하는 것은 불가능하다. 아무리 자기가 잘한다 한들 팀의 프로젝트 이해도에 기여하지 못한다면 무슨 소용이 있을까. 결국엔 자신의 강점을 팀 전체에 전염시킬 수 있는 사람이야 말로 진짜 고수가 아닐까라는 생각을 한다. 그리고 개발을 잘 하려면 코딩 외에도 알아야할 것이 많다. 어떤 사람들은 이런저런 개발 잡지식을 터득하는 것에 재미를 느끼고 그것이 전문성을 키워줄 것이라 믿는다. 나는 이런식의 성장을 부정하진 않지만 배워야할게 너무 많기 때문에 무엇을 배울지에 대한 기준을 잘 세우는게 더 중요하다고 생각한다.
개발을 잘한다라는 것에는 분명 사람들마다 의견의 차이가 있겠지만, 내 기준 개발을 잘하는 사람은 도구에 의존하지 않으면서 여러 도구를 잘 다룰 수 있는 사람이다. 변화가 워낙 빠른 분야이다보니 패러다임이 항상 바뀔 것을 생각해서 [[개발자가 갖춰야할 개발외 능력]]을 더욱 길러두는 것도 좋은 것 같다. 예를 들어 특정 라이브러리를 잘 쓰기보다, 어느 라이브러리를 사용하게 되든 관련 문서를 잘 찾고 빠르게 사용법을 숙지해서 적용할 수 있는 능력이나, 어떤 라이브러리가 서비스에 적절한지 [[선택하는 능력]]이 더 중요하다. 덧붙여 인터넷에는 영어로된 개발 레퍼런스가 많기 때문에 영어를 잘하는 것도 좋은 개발자가되는 능력 중 하나라고 할 수 있을 것 같다.
너무 특정 기술 스택에 치중하게되면 스스로 다른 방법은 생각할 수 없게 된다. 어느 순간 "내 길은 이 길뿐이야"라는 생각을 하게 될 수도 있다. 그러나 개발자는 결국 문제를 해결하는 직종이고, 대개 문제 해결에있어 이렇다할 정답은 없다. 무조건 최신 스택을 사용한다고 해서 다 해결되는 것도 아니고 코드를 기막히게 짠다고 해서 다 해결되는 것도 아니다. 그러니 자신이 개발자로서 목표하는 바가 높다면, 더더욱 최근에 많이 생겨난 붙여진 이름들에 목매달아선 안된다. 코드레벨에서 정말 능력이 있는 사람이 여러 기술을 시간을 들여 공부하지 않는다면 코드레벨에서 모든 것을 해결하려 할 것이고. 자기가 프론트엔드 개발자라고 프론트엔드만 하는 사람은 모든 문제를 클라이언트 쪽에서 처리하려 할 것이다. 문제 해결에 있어 사로잡힌 사고는 독이된다. 정말 아는 만큼 보일 뿐이다. 물론 적성이란게 있긴 하다. 그러나 적어도 개발에 있어서 (특히 저연차에) 자신의 적성을 확고히 여기는 것은 득보다 실이 큰것 같다.
사실 이건 개발자에게 한정된 내용은 아니다. 자신이 무엇을 할 수 있는지를 스스로가 제한하지 않는 마음가짐이 중요하다. 물론 모든 것을 다 할 수는 없겠지만 그래도 가능성을 열어두는 것이 좋다.
위에 적진 않았지만 웹 개발 생태가 어떻게 변화해왔는지 본 사람으로써 요즘 보이는 꼬리에 꼬리를 무는 툴체인은 견고하고 편리하다기보다 배보다 배꼽이 더 커졌다고 느껴진다. 나보다 이를 한껏 더 신랄하게 비판한 글(Is the madness ever going to end?)을 최근에 발견해서 공유한다. 컴퓨터 기술 분야는 마치 모래성같다. 때문에 더 위에 쌓일 수록 더 쉽게 바람에 날려가진 않을까 생각한다. 그래서 내가 자꾸 기술 스택보다는 개발에 있어 최대한 범용적이면서 실용적인 능력이 무엇인지 고민하고 개발하려는지 모른다.
다시 정리해보자 [[웹 프론트엔드 개발 어떻게]]
다른 관점을 얻어가는 때